home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000001_news@newsmaster….columbia.edu _Tue Sep 1 18:10:13 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA24201
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 1 Sep 1998 18:10:13 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA10615
  7.     for kermit.misc@watsun; Tue, 1 Sep 1998 18:10:13 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!vixen.cso.uiuc.edu!news.indiana.edu!not-for-mail
  9. From: jsue@cs.indiana.edu (jeff l sue)
  10. Newsgroups: comp.os.vms,comp.protocols.kermit.misc
  11. Subject: Re: How I implemented an application using C-Kermit for VMS
  12. Date: 1 Sep 1998 22:08:43 GMT
  13. Organization: NOT!
  14. Lines: 36
  15. Message-ID: <6shr9b$qsq$1@jetsam.uits.indiana.edu>
  16. References: <6s1kq5$65p$1@client3.news.psi.net> <6sfhis$4hi$1@jetsam.uits.indiana.edu> <6sh08l$1dv$1@apakabar.cc.columbia.edu>
  17. NNTP-Posting-Host: sheepskin.cs.indiana.edu
  18. X-Newsreader: trn 4.0-test66 (4 June 1998)
  19. Xref: news.columbia.edu comp.os.vms:185148 comp.protocols.kermit.misc:9158
  20.  
  21. In article <6sh08l$1dv$1@apakabar.cc.columbia.edu>,
  22. Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  23. >In article <6sfhis$4hi$1@jetsam.uits.indiana.edu>,
  24. >jeff l sue <jsue@cs.indiana.edu> wrote:
  25. >: In article <6s1kq5$65p$1@client3.news.psi.net>,
  26. >: Bob Kennedy <bkennedy@peco-energy.com> wrote:
  27. >: >
  28. >That's the good thing about alpha paging.  TAP is a protocol that lets the
  29. >page sender know whether the page was delivered successfully -- at least to
  30. >the paging service.  Of course it is the paging service's responsibility
  31. >to deliver it to the pager.  And of course it is also the responsibility of
  32. >the person carrying the page to read the page promptly and respond to it,
  33. >but that's somewhat beyond software control.
  34. >
  35.  
  36. Right, but my comments address the latter part of your paragraph:  Something
  37. needs to insure that the receiver actually got the message.  There are many
  38. different reasons that the page may not make it. For example (real world
  39. experience):  Pager accidentally turned off (by children), pager lost,
  40. battery died, on airplane when page happened, inept/unwilling receiver, etc.
  41.  
  42. The C-Kermit solution can be used to send the page, but some other complexity
  43. needs to be added to the paging application that provides for positive 
  44. confirmation from the receiver that the page got through.  If that confirmation
  45. doesn't arrive within x-minutes, then escalate one level - which may mean just
  46. trying again to the same pager.  Wait x-more minutes, then escalate to level2,
  47. etc.  At some point, upper management should be in the escalation process.
  48.  
  49. Without this, the effort spent on the paging application could result in
  50. messages going into the bit-bucket.
  51.  
  52. -- 
  53. JLS --    *I* said that - since I can     | Help stamp out abolitionists!
  54.     barely speak for myself, don't    | 
  55.     even think of blaming someone    | Ignorance is bliss... 
  56.     else.                |         for awhile anyway...